Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dealing with transient problems #14

Merged
merged 14 commits into from
Nov 9, 2016
Merged

Dealing with transient problems #14

merged 14 commits into from
Nov 9, 2016

Conversation

bunop
Copy link
Contributor

@bunop bunop commented Jun 16, 2016

Hi,

I've updated code. Briefly I have:

  • updated documentation
  • fixed setup.py to use the more recent requests library
  • simulating something bad has happened and Something went wrong while fetching from LDFeatureContainerAdaptor (400) transient problems
  • added timeouts, sleeping time and retry last query

Thank you,

Paolo

bunop added 10 commits June 14, 2016 17:31
install_requires=['requests>=1.0.0, <2.0.0'] implies that request is
uninstalled if a more recent version is installed. This behaviour
will be removed, however module seems to work even with more
recent version of request
Scaling n of request per seconds if more processes are active in a
limited account
if a request fails with a known transitory error (something bad has happened,
Something went wrong while fetching from LDFeatureContainerAdaptor), it could
be done automatically (for a certain amount of retries) before raising exceptions
By settings timeouts and internal retries I can improve performances
(even with sleeping times between each retry)
The main problem when submitting more queries than permitted is that
ensembl limit 15 request per second, so there's no need to fix the
internal number. By submitting more than 15 request per second, the
EnsemblRestRateLimitError exception will be reaised. The user will check
his code to deal with exceptions or avoding to submit multiple clients
using pyEnsemblRest API
@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling aef872b on bunop:testing into 773102a on pyOpenSci:master.

@bunop
Copy link
Contributor Author

bunop commented Jun 16, 2016

The only problems I can't deal are transitory problems on results (result is different when submitting two times the same request - as here, scrutinizer failed a previous passed test). When such problems arise, we have to contant the ensembl team

An ensembl id used in test was removed recently. I've splitted code
in order to do small functions in my classes
@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling 4de9e6b on bunop:testing into 773102a on pyOpenSci:master.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling 750b80c on bunop:testing into 773102a on pyOpenSci:master.

@bunop
Copy link
Contributor Author

bunop commented Nov 4, 2016

I rewrote some functions in order to improve scrutinizer score. I've updated tests since one entry was removed from ensembl.

Regards,

Paolo

@gawbul gawbul merged commit 715ba4b into gawbul:master Nov 9, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants